-
Notifications
You must be signed in to change notification settings - Fork 111
build_linux.sh: add option to choose toolchain #730
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
419e179 to
60b7944
Compare
|
Nice PR, @Be-ing do you have any results links for Actions? I can't seem to trigger an external branch workflow in our Actions. |
4751eda to
4588bbe
Compare
e8809b3 to
57494f4
Compare
That may be because the action was set to trigger only on pushing a tag. For testing I added a commit changing that to run on any push. A successful build on my fork is here: https://github.com/Be-ing/rust-sdks/actions/runs/18477988272 When you decide this is ready to merge, I can rebase to remove that commit. |
|
FWIW I tested building with the gn option I can only get |
ab416bb to
a326958
Compare
|
hey @Be-ing, the issue seems to have returned to the original point. rust-sdks # export LK_CUSTOM_WEBRTC=`pwd`/webrtc-sys/libwebrtc/linux-x64-release
rust-sdks # cd livekit-ffi && cargo build --releaseI got the following error:
|
|
Here are some key information, cargo build the ffi can only correctly link libraries in the objdump info form # objdump -p gcc-linux-x64-release/lib/libwebrtc.a
...
ice_credentials_iterator.o: file format elf64-x86-64
transport_description.o: file format elf64-x86-64and form # objdump -p linux-x64-release/lib/libwebrtc.a
...
ice_credentials_iterator.o: file format elf64-little
transport_description.o: file format elf64-little |
|
Interesting, I have not seen that error before 🤔 What distro are you using? I notice the error mentions /usr/bin/ld, which is probably the GNU linker. Rust no longer uses that by default, so I suspect you haven't updated your Rust toolchain in a while. Can you try linking with lld, mold, or wild? You can configure the linker by adding this section to ~/.config/cargo.toml [target.aarch64-unknown-linux-gnu]
linker = "clang"
rustflags = [
"-C", "link-arg=--ld-path=wild"
]Does that error only occur with the chromium-llvm toolchain? |
a326958 to
c145af2
Compare
|
Ah, I used GNU ld on x86-64 with a chromium-llvm built libwebrtc.a and reproduced the linker error running |
|
Linking fails with GNU ld with a gcc-built libwebrtc.a as well 🫠 |
|
I could put some hacks in build.rs to use lld, mold, and wild in preference to GNU ld. That doesn't seem necessary though now that Rust ships and uses lld by default. |
I can reproduce these issues on |
|
@cloudwebrtc Are you able to link with another linker? |
|
I am now doubting that there is any use case for the |
c145af2 to
8ce0e89
Compare
This adds a --toolchain CLI option to the script that can be either
* gnu
* llvm
* chromium-llvm
The gnu and llvm options use the system's toolchain. chromium-llvm
uses Chromium's prebuilt LLVM toolchain.
Previously, the script tried to combine the system's gcc with
libstdc++ from Chromium's Debian sysroot, which failed to find
glibc headers:
[1/4184] CXX obj/third_party/abseil-cpp/absl/base/base/cycleclock.o
FAILED: obj/third_party/abseil-cpp/absl/base/base/cycleclock.o
g++ -MMD -MF obj/third_party/abseil-cpp/absl/base/base/cycleclock.o.d -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_OZONE=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_LIBCPP_HARDENING_MODE=_LIBCPP_HARDENING_MODE_NONE -D_GLIBCXX_ASSERTIONS=1 -DCR_SYSROOT_KEY=20250129T203412Z-1 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DABSL_ALLOCATOR_NOTHROW=1 -I.. -Igen -I../third_party/abseil-cpp -fno-strict-overflow -fno-ident -fno-strict-aliasing -fstack-protector -funwind-tables -fPIC -pipe -pthread -m64 -msse3 -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -O2 -fdata-sections -ffunction-sections -fno-math-errno -fno-omit-frame-pointer -g0 -fvisibility=hidden -Wno-unused-local-typedefs -Wno-maybe-uninitialized -Wno-deprecated-declarations -Wno-comments -Wno-packed-not-aligned -Wno-missing-field-initializers -Wno-unused-parameter -Wno-psabi -std=gnu++2a -Wno-changes-meaning -fno-exceptions --sysroot=../build/linux/debian_bullseye_amd64-sysroot -fvisibility-inlines-hidden -Wno-narrowing -Wno-class-memaccess -Wno-invalid-offsetof -c ../third_party/abseil-cpp/absl/base/internal/cycleclock.cc -o obj/third_party/abseil-cpp/absl/base/base/cycleclock.o
In file included from /usr/include/c++/15/bits/version.h:51,
from /usr/include/c++/15/atomic:50,
from ../third_party/abseil-cpp/absl/base/internal/cycleclock.h:45,
from ../third_party/abseil-cpp/absl/base/internal/cycleclock.cc:23:
/usr/include/c++/15/x86_64-redhat-linux/bits/c++config.h:3:10: fatal error: bits/wordsize.h: No such file or directory
3 | #include <bits/wordsize.h>
| ^~~~~~~~~~~~~~~~~
8ce0e89 to
020f52a
Compare
There's no point to using the Debian sysroot livekit#730 (comment)
There's no point to using the Debian sysroot livekit#730 (comment)
This adds a --toolchain CLI option to the script that can be either
The gnu and llvm options use the system's toolchain. chromium-llvm uses Chromium's prebuilt LLVM toolchain with its Debian sysroot.
Previously, the script tried to combine the system's gcc with libstdc++ from Chromium's Debian sysroot, which failed to find glibc headers: